1. Field of the Invention
This invention relates to a method for selecting an optimal path for packets through a data network including network address translators.
2. Description of the Related Art
Data networks, such as IP networks, provide an avenue for multimedia communication between end-points such as computer stations and IP phones. These networks even allow telephone calls to be handled between end-users using techniques such as Voice over IP (VoIP) and the like.
Data networks generally include private networks and public networks, arranged hierarchically. The private networks usually involve individual computer users and local area networks while the public networks are generally owned by service providers and may interconnect over more extensive areas. In order to manage the limited number of addresses available to private networks and to maintain security on the data networks, a firewall and a network address translation (NAT) device are typically installed at the interface between two separate networks. Although a NAT device provides a level of security to the network users it serves and even though it can dynamically allocate the limited number of public addresses that it has at its disposal for all the network users, a NAT device nonetheless increases the difficulty with which calls can be made from one party to another. This difficulty occurs because any NAT device in the data path of the bearer channel alters the address of the packets thereby complicating call dynamics.
This difficulty is manifested in a number of different ways. First, most media traffic, such a voice, video, and the like, is carried in user datagram packets (UDP). UDP is a simple, flexible protocol well suited to real time traffic from multimedia applications. UDP packets pose a high security risk because they cannot be easily traced. It is normal policy for firewalls and NAT devices to block all incoming UDP packets. NAT devices require an outgoing packet from an internal device to be sent to an external host before the NAT device will accept UDP packets from that host back to the internal device. In this way, unsolicited UDP packets are effectively blocked.
Each device in a network can have its own private IP address. A NAT device translates private IP addresses and port numbers within the private network into public internet (IP) addresses when the communication passes between private and public networks or passes between networks within a common network that use different addressing spaces. This translation allows a limited number of public IP addresses to serve the needs of private network subscribers including very large corporations as well as service providers with limited IP address space. As data such as a media stream or the like is sent from the private network to the public network and vice versa, the user device within the private network is dynamically assigned a specific address and port number in the public address space by the NAT device. Each NAT device maintains a binding table that links private addresses and port numbers with public addresses and port numbers. But as stated earlier, these bindings are only initiated by outgoing traffic from the private network subscribers. There is no mechanism for the NAT device to create a binding table entry for incoming traffic. This is a particular problem for IP telephony applications where the IP phone is expected to receive packets such as network announcements, ringback tones, and the like before sending packets out.
These problems are exacerbated by the requirements of messaging protocols. For example, end-to-end Session Initiation Protocol (SIP) messaging between end-users contains details of the private network addresses and ports designated by the end-users for traffic flow. When end-users attempt to use these private addresses for communication, the connection fails because the network does not know how to forward the packets to the private addresses. This issue also applies to other signaling protocols such as H.323 and Media Gateway Control Protocol (MGCP), to name a few.
Several approaches have been proposed for dealing with the problem presented by NAT traversal. These approaches include Universal Plug and Play (UPnP), Simple Traversal of UDP through Network Address Translation Devices (STUN), Traversal Using Relay NAT (TURN), Application Layer Gateway (ALG), manual configuration techniques, and tunneling or pin-holing techniques. Some of these techniques such as STUN and TURN require the use of additional equipment such as servers and establishment of a client-server relationship with network users. Some of these techniques require labor intensive involvement of a system administrator to make the necessary connections. Others present potential security risks. None regularly provide an optimal path through the network, at least not without considerable effort.
One other technique being proposed in a standards setting organization (IETF) is known as Interactive Connectivity Establishment or ICE. It allows user datagram (UDP) packets of peer-to-peer applications to traverse NAT devices and firewalls for multimedia session signaling protocols such as SIP. The technique relies on the use of STUN and TURN servers together with the mutual cooperation of the users in a session. In this technique and through an ICE client routine, the calling client will consult its network database to locate the network traversal to a default TURN server. The called client initiates the same activity. The database and the traversal data therein are manually loaded and must be updated by each client to remain correct as the network changes from day to day. The traversal represents a default path through the network that is generally non-optimal but is guaranteed to provide the necessary connectivity. Regardless of the optimality of the default path, the ICE procedure reserves resources, such as TURN servers throughout the network along the traversal, to the call until such time as they are released. According to ICE, the clients will then initiate an exhaustive search by trial and error for an optimal (highest priority) network call path connecting the clients together. This technique is time consuming, utilizes important network resources, and requires a significant amount of administrative overhead to maintain the distributed databases at each client computer.